1. Field of the Invention
The present invention generally relates to managing access to a data abstraction model abstractly describing physical data and, more particularly, to creating a security model for a data abstraction model abstractly describing data in a database.
2. Description of the Related Art
Databases are computerized information storage and retrieval systems. The most prevalent type of database is the relational database, a tabular database in which data is defined so that it can be reorganized and accessed in a number of different ways. A distributed database is one that can be dispersed or replicated among different points in a network. An object-oriented programming database is one that is congruent with the data defined in object classes and subclasses.
Regardless of the particular architecture, a database management system (DBMS) can be structured to support a variety of different types of operations for a requesting entity (e.g., an application, the operating system or an end user). Such operations can be configured to retrieve, add, modify and delete information being stored and managed by the DBMS. Standard database access methods support these operations using high-level query languages, such as the Structured Query Language (SQL). The term “query” denominates a set of commands that cause execution of operations for processing data from a stored database. For instance, SQL supports four types of query operations, i.e., SELECT, INSERT, UPDATE and DELETE. A SELECT operation retrieves data from a database, an INSERT operation adds new data to a database, an UPDATE operation modifies data in a database and a DELETE operation removes data from a database.
Unfortunately, generating queries using SQL (and other query languages) may require a detailed understanding of the possibly complex physical layout of the underlying database and interpretation of cryptic field names. For some applications, to facilitate the query building process, an abstraction model may be utilized that, in effect, hides some of the complexities of the physical layout of the underlying database from users. The abstraction model may include logical fields with recognizable names that map to corresponding physical fields of the underlying database. “Abstract” queries may be generated containing conditions based on the logical fields. Upon issuance, the logical fields of an abstract query may be mapped to corresponding physical fields to create a physical or “concrete” query. The concepts of data abstraction and abstract queries are described in detail in the commonly owned, co-pending application Ser. No. 10/083,075, entitled “APPLICATION PORTABILITY AND EXTENSIBILITY THROUGH DATABASE SCHEMA AND QUERY ABSTRACTION”, filed Feb. 26, 2002, herein incorporated by reference in its entirety.
As described in the related application Ser. No. 10/083,075 (hereinafter referred to as the '075 application), logical fields are typically mapped to a particular physical field in a physical database. For instance, if the physical database was implemented as a relational database, a particular logical field would be mapped to a particular column within a relational table. Thus, using a data abstraction model according to the framework of the '075 application, abstract queries can be constructed based on the framework without regard for the makeup of the underlying physical data.
One type of functionality that a framework such as the one of the '075 application may need to support is access management. More specifically, by accessing a data abstraction model according to the framework of the '075 application, a user may circumvent access rights implemented at the physical layer. For instance, the data abstraction model can be configured to present data of a given column of a table in an underlying physical database to the user even though the user is not allowed to access the given column at the physical layer. Accordingly, it may be desirable to implement a logical security model that reflects the access rights implemented at the physical layer in order to guarantee data security with respect to data of the underlying physical database. However, creation of any security artifact, including for a logical security model over a data abstraction model, is complex and time consuming. This is because each artifact must be rigorously and carefully constructed since even small errors in a resulting security model can leave the underlying physical database vulnerable to data corruption or unwanted disclosure of data.
Therefore, there is a need for an efficient technique for creating a logical security model for a data abstraction model abstractly describing data in a database.